NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part2/12792

Internet Message Format | 1996-08-05 | 8.6 KB

Path: mail2news.demon.co.uk!genesis.demon.co.uk
From: Lawrence Kirby <[e-mail]>
Newsgroups: comp.lang.c
Subject: Re: Hungarian notation - whoops!
Date: Tue, 02 Apr 96 19:37:05 GMT
Organization: none
Message-ID: <[e-mail]>
References: <[e-mail]> <4fc157$[e-mail]> <dewar.823793746@schonberg> <4fms62$[e-mail]> <[e-mail]> <4g9255$[e-mail]> <[e-mail]> <4h6gbp$[e-mail]>
Reply-To: [e-mail]
X-NNTP-Posting-Host: genesis.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
X-Mail2News-Path: genesis.demon.co.uk

In article <4h6gbp$[e-mail]>
           [e-mail] "Richard A. O'Keefe" writes:

<Sorry, I put thin on the back burner for a while, I nearly lost it>

>I complain about abs(X) giving wrong answers.
>
>Lawrence Kirby <[e-mail]> writes:
>
>>Checking against overflow is required whatever representation is used.
>
>In the case of unary minus and abs, this is not true.
>Those are the functions I was discussing.

Any my point remains that if you are checking against overflow you're
just moving the problem somewhere else, not eliminating it.

>>Once this is established using 2's complement is no worse than any other
>>representation.  Did you see my earlier reply in the thread on this subject?
>
>Yes, but it was neither comfort nor assistance.
>
>>If nothing else it seems to me that 2's complement is a big win with
>>regards to implementing multiple-precision arithmetic since lower order
>>bits of the result of most operations don't depend on the signs of the
>>operands or the sign of the result.
>
>I have implemented multiple-precision arithmetic, and I must say I found
>2s-complement a confounded nuisance.

I have too and it made the operation trivial (I'm talking about assembler
rather than C).

> What I wanted, and what I used,
>was arithmetic on N-bit natural numbers with overflow.  In short, what
>I wanted for multiple precision arithmetic was
>        N-bit natural + N-bit natural -> N-bit natural + carry
>        N-bit natural - N-bit natural -> N-bit natural + borrow
>        N-bit natural x N-bit natural -> 2N-bit natural
>        2N-bit natural (/,%) N-bit natural -> N-bit natural, N-bit natural
>Interpreting any of these as signed gave rise to serious complications.

2's complement systems provide this almost for nothing since for + and -
at least the bit manipulations are the same as unsigned, you just test a
different set of conditions or flags. The common 2's complement archetectures
I've come across support the interpretation of an operation as either
2's complement or unsigned.

More importantly the final status of the magnitude bits after + or - is
independent of the sign bits which is a big win for multiple precision
arithmetic - it means you can perform the operation on the lowest order
word and progress to the highest order word and when you get there you've
finished. How would you do it using a sign-magnitude representation?

>Oh dear.  I'm beginning to sound like Hermann Rubin.
>
>>>The practical consequence of this is that responsibility for ensuring that
>>>the input to unary minus or absolute value is in range is passed onto the
>>>programmer.  It is that which I am complaining about.  It doesn't make my
>>>life as a programmer one teeny tiny bit easier.
>
>>It doesn't make it any harder either - see my earlier post.
>
>I saw your earlier post all right, and I didn't agree with it.
>Perhaps in theory you might be right.  But in PRACTICE, it isn't true.
>I have, for example, seen Pascal compilers where addition, subtraction,
>and multiplication were checked for overflow, but unary minus, absolute
>value, and division, were NOT checked for overflow, because they "obviously"
>couldn't.  But they can.

Whether the compiler checks for overflow or not on basic arithmetic
operations has nothing to do with whether the system uses 2's complement or
some other representation, it is just a design decision for the compiler.`

>(Against myself, I must admit that one Pascal compiler for SPARCs did check
>the overflow flag after multiplication, but the implementor hadn't bothered
>to check what the multiplication routine actually _did_:  Sun's code always
>cleared the overflow bit whatever happened.  Ouch!)
>
>>>Modular arithmetic in Ada 95 *is* the ticket for portable hackery.
>>>Unsigned arithmetic in C is indeed defined to be modulo 2**n for some
>>>n, but the bounds on n are very very loose, and the price of portability
>>>is much programmer-inserted masking.
>
>>Well, a small amount of masking.
>
>Every operation except comparison needs it.  That's not a small amount.

No, for most 2's complement/unsigned operations higher order bits don't
affect lower order bits. That means that most masking on operations performed
in registers can be eliminated and in many cases a mask is only needed before
writing the result to memory.

>>True, modulo arithmetic isn't useful in contexts where it simply generates
>>the wrong result (however it does make it easy to test for overflow after
>>an unsigned operation).
>
>It depends on what you mean by easy.  There are machines where the unsigned
>arithmetic operations don't set the carry/borrow/overflow/whatever bit.

>There are others where there are minor glitches, e.g. on the M88100,
>        unsigned x, y;
>        x += y <<without overflow check>>
>        x += y <<with    overflow check>>
>        x += 1 <<without overflow check>>
>all take one instruction, but
>        x += 1 <<with   overflow check>>
>takes two instructions, and the integer multiply instruction delivers the
>bottom 32 bits with no overflow indication available at all.

I'm arguing about the merits of 2's complement in general, not wjether there
are poor implementations of it. Implementations can be fixed and new
archetecture designs can be done properly. in their way microprocessors
like the 6502 got it right as indeed has the x86.

>I suspect that you mean that it is easy in C using unsigned arithmetic
>to test for overflow by using a short sequence of instructions.  I am
>well aware of that, and I am also aware that it isn't easy, although C++
>or Ada could let you do this without cluttering up the visual appearance
>of the code (user-overloaded inline operators).

Multiple-precision arithmetic isn't great, whatever the representation you
use. In my view 2's complement is still the best bet though unless you
can show me a very efficient method using some other representation.

>>Only if the code doesn't test for wrap to zero. Unsigned types make this
>>test very easy.
>
>YES BUT THEY MAKE IT ******NECESSARY*******.
>(and in C, they don't make it any easier than signed types, in practice).
>
>The whole point that I am making is that MY code gets cluttered up!

I agree but that's a different issue.

>>>Overflows aren't the problem.  Restricted machine arithmetic is the problem.
>
>>It depends on where you put the limit. Language support for multiple-precision
>>arithmetic or specified precision beyond 64 bits (or possibly 128 bits)
>>has some uses but they are rare across the whole spectrum of code.
>
>I haven't been asking for multiple precision arithmetic.

I made the point that multiple-precision arithmetic was a strong mark in
2's complement's favour - you disagreed.

>I haven't been asking for specified precision beyond 64 bits.
>(In my computing youth, I had 78 bits + sign and was happy.  Sigh.)
>All I keep on saying is that
>    - hardware arithmetic which delivers "wrong" results
>    - combined with compilers that don't check the warning flags
>      that ARE available in many architectures
>push a lot of implementation complexity into MY code that doesn't belong
>there, and I don't like it.

There's a valid compiler/language issue there but it has little or nothing
to do with 2's complement.

There do seem to be separate issues that are being confused here. In this
and certainly previous postings you've indicated a string dislike for
2's complement but haven't shown any clear disadvantages to it (there is
abs() but in practice I've never come across a situation where that was an
issue). On the other hand I see that in nearly all cases that show a
difference 2's complement has the advantage.

A separate issue is whether an archetecture, language or implementation has
adequate support for boundary checking. It is certainly try that C's
boundary checking leaves a lot to be desired (if it exists at all).

--
-----------------------------------------
Lawrence Kirby | [e-mail]
Wilts, England | [e-mail]
-----------------------------------------